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Status of this Memo 


This memo provides information for the Internet community. It does 


not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 


Copyright (C) The Internet Society (2000). All Rights Reserved. 


Abstract 


While the X.500 standards define many useful attribute types [X520] 
and object classes [X521], they do not define a person object class 
that meets the requirements found in today’s Internet and Intranet 

directory service deployments. We define a new object class called 
inetOrgPerson for use in LDAP and X.500 directory services that 


extends the X.521 standard organizationalPerson class to meet these 
needs. 
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1. Background and Intended Usage 


The inetOrgPerson object class is a general purpose object class that 
holds attributes about people. The attributes it holds were chosen 
to accommodate information requirements found in typical Internet and 
Intranet directory service deployments. The inetOrgPerson object 
class is designed to be used within directory services based on the 
LDAP [RFC2251] and the X.500 family of protocols, and it should be 
useful in other contexts as well. There is no requirement for 
directory services implementors to use the inetOrgPerson object 
class; it is simply presented as well-documented class that 
implementors can choose to use if they find it useful. 
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The attribute type and object class definitions in this document are 
written using the BNF form of AttributeTypeDescription and 
ObjectClassDescription given in [RFC2252]. In some cases lines have 
been folded for readability. 


Attributes that are referenced but not defined in this document are 
included in one of the following documents: 


The COSINE and Internet X.500 Schema [RFC1274] 


Definition of an X.500 Attribute Type and an Object Class to Hold 
Uniform Resource Identifiers (URIs) [RFC2079] 


A Summary of the X.500(96) User Schema for use with LDAPv3 
[RFC2256] 


See Appendix A for a summary of the attribute types, associated 
syntaxes, and matching rules used in this document. 


2. New Attribute Types Used in the inetOrgPerson Object Class 
2.1. Vehicle license or registration plate. 


This multivalued field is used to record the values of the license or 
registration plate associated with an individual. 


( 2.16.840.1.113730.3.1.1 NAME "carlicense" 
DESC 'vehicle license or registration plate' 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


2.2. Department number 


Code for department to which a person belongs. This can also be 
strictly numeric (e.g., 1234) or alphanumeric (e.g., ABC/123). 


( 2.16.840.1.113730.3.1.2 
NAME "departmentNumber" 
DESC ‘identifies a department within an organization’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
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2.3. Display Name 


When displaying an entry, especially within a one-line summary list, 
it is useful to be able to identify a name to be used. Since other 
attribute types such as 'cn' are multivalued, an additional attribute 
type is needed. Display name is defined for this purpose. 


(.2.16.840.1.113730.3.1.241 
NAME "displayName" 
DESC ‘preferred name of a person to be used when displaying entries’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


2.4. Employee Number 


Numeric or alphanumeric identifier assigned to a person, typically 
based on order of hire or association with an organization. Single 
valued. 


( 2.16.840.1.113730.3.1.3 
NAME "emploveeNumber" 
DESC ‘numerically identifies an employee within an organization’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


2.5. Employee Type 


Used to identify the employer to employee relationship. Typical 
values used will be "Contractor", "Employee", "Intern", "Temp", 
"External", and "Unknown" but any value may be used. 


( 2.16.840.1.113730.3.1.4 

NAME "emploveeType" 

DESC 'type of employment for a person' 
EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
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2.6. JPEG Photograph 


Used to store one or more images of a person using the JPEG File 
Interchange Format [JFIF]. 


( 0.9.2342.19200300.100.1.60 
NAME " jpegPhoto" 
DESC "a JPEG image’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) 


Note that the jpegPhoto attribute type was defined for use in the 
Internet X.500 pilots but no referencable definition for it could be 
located. 


2.7. Preferred Language 


Used to indicate an individual’s preferred written or spoken 
language. This is useful for international correspondence or human- 
computer interaction. Values for this attribute type MUST conform to 
the definition of the Accept-Language header field defined in 
[RFC2068] with one exception: the sequence "Accept-Language" ":" 
should be omitted. This is a single valued attribute type. 


(^2.16.9840.1.113730.3.1.39 
NAME 'preferredLanguage' 
DESC 'preferred written or spoken language for a person' 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


2.8. User S/MIME Certificate 


A PKCS#7 [RFC2315] SignedData, where the content that is signed is 
ignored by consumers of userSMIMECertificate values. It is 
recommended that values have a ‘contentType’ of data with an absent 
‘content’ field. Values of this attribute contain a person's entire 
certificate chain and an smimeCapabilities field [RFC2633] that at a 
minimum describes their SMIME algorithm capabilities. Values for 
this attribute are to be stored and requested in binary form, as 
'userSMIMECertificate;binary'. If available, this attribute is 
preferred over the userCertificate attribute for S/MIME applications. 


( 2.16.840.1.113730.3.1.40 
NAME 'userSMIMECertificate' 
DESC "PKCS#7 SignedData used to support S/MIME’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) 
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2.9. User PKCS #12 


PKCS #12 [PKCS12] provides a format for exchange of personal identity 


information. When such information is stored in a directory service, 
the userPKCS12 attribute should be used. This attribute is to be 
Stored and requested in binary form, as 'userPKCS12;binary'. The 


attribute values are PFX PDUs stored as binary data. 


( 2.16.840.1.113730.3.1.216 
NAME 'userPKCS12' 
DESC 'PKCS #12 PFX PDU for exchange of personal identity information’ 
SYNTAX .:1:34:6:01.4.:1.1466.115.121.125-) 


3. Definition of the inetOrgPerson Object Class 


The inetOrgPerson represents people who are associated with an 
organization in some way. It is a structural class and is derived 
from the organizationalPerson class which is defined in X.521 [X521]. 


( 2.16.840.1.113730.3.2.2 

NAME 'inetOrgPerson' 

SUP organizationalPerson 

STRUCTURAL 

MAY ( 
audio $ businessCategory $ carLicense $ departmentNumber $ 
displayName $ employeeNumber $ employeeType $ givenName $ 
homePhone $ homePostalAddress $ initials $ jpegPhoto $ 
labeledURI $ mail $ manager $ mobile $ o $ pager S$ 
photo $ roomNumber $ secretary $ uid $ userCertificate $ 
x500uniqueIdentifier $ preferredLanguage $ 
userSMIMECertificate $ userPKCS12 


For reference, we list the following additional attribute types that 
are part of the inetOrgPerson object class. These attribute types 
are inherited from organizationalPerson (which in turn is derived 
from the person object class): 
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MUST ( 
cn $ objectClass $ sn 


MAY ( 
description $ destinationIndicator $ facsimileTelephoneNumber $ 
internationaliSDNNumber $ 1 $ ou $ physicalDeliveryOfficeName $ 
postalAddress $ postalCode $ postOfficeBox $ 
preferredDeliveryMethod $ registeredAddress $ seeAlso $ 
st $ street $ telephoneNumber $ teletexTerminalIdentifier $ 
telexNumber $ title $ userPassword $ x121Address 

) 


4. Example of an inetOrgPerson Entry 


The following example is expressed using the LDIF notation defined in 
[LDIF]. 


version: 1 

dn: cn-Barbara Jensen,ou-Product Development, dc=siroe, dc=com 
objectClass: top 

objectClass: person 

objectClass: organizationalPerson 
objectClass: inetOrgPerson 

cn: Barbara Jensen 

cn: Babs Jensen 

displayName: Babs Jensen 

Sn: Jensen 

givenName: Barbara 

initials: BJJ 

title: manager, product development 

uid: bjensen 

mail: bjensen@siroe.com 

telephoneNumber: +1 408 555 1862 
facsimileTelephoneNumber: +1 408 555 1992 
mobile: +1 408 555 1941 

roomNumber: 0209 

carLicense: 6ABC246 

o: Siroe 

ou: Product Development 

departmentNumber: 2604 

employeeNumber: 42 

employeeType: full time 

preferredLanguage: fr, en-gb;q-0.8, en;q-0.7 
labeledURI: http://www.siroe.com/users/bjensen My Home Page 
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Security Considerations 


Attributes of directory entries are used to provide descriptive 
information about the real-world objects they represent, which can be 
people, organizations or devices. Most countries have privacy laws 
regarding the publication of information about people. 


Transfer of cleartext passwords are strongly discouraged where the 
underlying transport service cannot guarantee confidentiality and may 
result in disclosure of the password to unauthorized parties. 
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9. Appendix A - inetOrgPerson Schema Summary 


This appendix provides definitions of all the attribute types 
included in the inetOrgPerson object class along with their 
associated syntaxes and matching rules. 


9.1. Attribute Types 
9.1.1. New attribute types that are defined in this document 


( 2.16.840.1.113730.3.1.1 NAME "carlicense" 
DESC ‘vehicle license or registration plate’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


( 2.16.840.1.113730.3.1.2 
NAME "departmentNumber" 
DESC ‘identifies a department within an organization’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


( 2.16.840.1.113730.3.1.241 
NAME "displayName" 
DESC ‘preferred name of a person to be used when displaying entries’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


( 2.16.840.1.113730.3.1.3 
NAME "emploveeNumber" 
DESC ‘numerically identifies an employee within an organization’ 
EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
SINGLE-VALUE ) 


( 2.16.840.1.113730.3.1.4 
NAME "emploveeType" 
DESC 'type of employment for a person’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1:.3.6.1.4.1.1466.115.;121;:.1.15 ) 
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( 0.9.2342.19200300.100.1.60 
NAME " jpegPhoto" 
DESC "a JPEG image"! 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) 

Note: The jpegPhoto attribute type was defined for use in the 
Internet X.500 pilots but no referencable definition for it 
could be located. 


(-2:7T16.940.1.113730.-3.1. 539 
NAME "preferredlanguage" 
DESC ‘preferred written or spoken language for a person’ 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX: 1.3.6.1.4.1.1466.115.12T.1.15 
SINGLE-VALUE ) 


( 2.16.840.1.113730.3.1.40 
NAME 'userSMIMECertificate' 
DESC 'signed message used to support S/MIME’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 ) 


( 2.16.840.1.113730.3.1.216 
NAME 'userPKCS12' 
DESC 'PKCS #12 PFX PDU for exchange of personal identity information’ 
SYNTAX 1:3.6.1.4.1.1466.115.121.1.5.) 


9.1.2. Attribute types from RFC 2256 


Note that the original definitions of these types can be found in 
X.520. 


( 2.5.4.15 
NAME 'businessCategory' 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.151(128] ) 


( 2.5.4.3 
NAME "cn" 
SUP name ) 


( 2.5.4.13 
NAME "description" 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(1024) ) 
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22964 2.1 

NAME 'destinationIndicator' 

EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.44(128) ) 


2.5:4.23 
NAME 'facsimileTelephoneNumber' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 ) 


22524.42 
NAME "givenName" 
SUP name ) 


299.4443 
NAME "initials" 
SUP name ) 


2:94:25 

NAME 'internationaliSDNNumber' 

EQUALITY numericStringMatch 

SUBSTR numericStringSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36(16) ) 


25544.7 
NAME "1" 
SUP name ) 


2.5.4.0 

NAME ‘objectClass’ 

EQUALITY objectIdentifierMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 


2.5.4.10 
NAME 'o' 
SUP name ) 


2 5¢4- sl 1 
NAME "ou" 
SUP name ) 


2c5540219 

NAME 'physicalDeliveryOfficeName" 

EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(128) ) 
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(2.024... 1:8 

NAME 'postOfficeBox' 

EQUALITY caseIgnoreMatch 

SUBSTR caselgnoreSubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(40) ) 


Č 2.5.4,16 
NAME "postalAddress" 
EQUALITY caseIgnoreListMatch 
SUBSTR caselgnorelistSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 


(2:55... 17 
NAME "postalCode" 
EOUALITY caselgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(40) ) 


( 2.5.4.28 
NAME 'preferredDeliveryMethod' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.14 
SINGLE-VALUE ) 


( 2.5.4.26 
NAME 'registeredAddress' 
SUP postalAddress 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 


( 2.5.4.34 
NAME 'seeAlso' 
SUP distinguishedName ) 


( 2.5.4.4 
NAME "sn" 
SUP name ) 


( 2.5.4.8 
NAME "st" 
SUP name ) 


(2.5.4.9 
NAME "street" 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(128) ) 
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(22.5% 4 20 

NAME "telephoneNumber" 

EQUALITY telephoneNumberMatch 

SUBSTR telephoneNumberSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50(32) ) 


( 2.5.4.22 
NAME 'teletexTerminalldentifier' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 ) 


(.:2:5.,4.21 
NAME 'telexNumber' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 ) 


( 295.4. 12 
NAME "title" 
SUP name ) 


( 2.5.4.36 
NAME "userCertificate"! 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 


( 2.5.4.35 
NAME 'userPassword' 
EQUALITY octetStringMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40(128) ) 


( 2.5.4.24 
NAME 'x121Address' 
EQUALITY numericStringMatch 
SUBSTR numericStringSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36(15) ) 


( 2.5.4.45 

NAME 'x500UniqueIdentifier' 

EQUALITY bitStringMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 


Some attribute types included in inetOrgPerson are derived from the 
'name' and 'distinguishedName' attribute supertypes: 


( 2.5.4.41 
NAME "name" 
EQUALITY caseIgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(32768) ) 
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( 


2.5.4.49 

NAME "distinguishedName" 

EQUALITY distinguishedNameMatch 
SYNTAX 1.3.6.1:24:1.14066.115.121.1.12 .) 


Attribute types from RFC 1274 


0.9.2342.19200300.100.1.55 

NAME "audio" 

EQUALITY octetStringMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.40(250000) ) 


Note: The syntax used here for the audio attribute type is Octet 


String. RFC 1274 uses a syntax called audio which is not defined 
in RFC 1274. 


0.9.2342.19200300.100.1.20 

NAME "homePhone" 

EQUALITY telephoneNumberMatch 

SUBSTR telephoneNumberSubstringsMatch 
SYNTAX. 1.3.0.1.4.1.1466.115.121.1.50-) 


Note: RFC 1274 uses the longer name "homeTelephoneNumber". 


( 


0.9.2342.19200300.100.1.39 

NAME 'homePostalAddress' 

EQUALITY caseIgnoreListMatch 

SUBSTR caselgnorelistSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 


0.9.2342.19200300.100.1.3 

NAME "mail" 

EQUALITY caseIgnoreIA5Match 

SUBSTR caselgnoreIA5SubstringsMatch 

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26(256) ) 


Note: RFC 1274 uses the longer name 'rfc822Mailbox' and syntax OID 


of 0.9.2342.19200300.100.3.5. All recent LDAP documents and most 
deployed LDAP implementations refer to this attribute as "mail" 
and define the IA5 String syntax using using the OID 
1.3.6.1.4.1.1466.115.121.1.26, as is done here. 


0.9.2342.19200300.100.1.10 

NAME "manager! 

EOUALITY distinguishedNameMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 
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( 0.9.2342.19200300.100.1.41 
NAME "mobile" 
EQUALITY telephoneNumberMatch 
SUBSTR telephoneNumberSubstringsMatch 
SYNTAX. 14.3.060.1.4.1.1466.115.121.1.50-) 
Note: RFC 1274 uses the longer name 'mobileTelephoneNumber'. 


( 0.9.2342.19200300.100.1.42 
NAME "pager! 
EQUALITY telephoneNumberMatch 
SUBSTR telephoneNumberSubstringsMatch 
SYNTAX 1.3:6.1.4.1.1466:115.121:1.50:J 
Note: RFC 1274 uses the longer name 'pagerTelephoneNumber'. 


( 0.9.2342.19200300.100.1.7 
NAME 'photo' ) 

Note: Photo attribute values are encoded in G3 fax format with an 
ASN.1 wrapper. Please refer to RFC 1274 section 9.3.7 for 
detailed syntax information for this attribute. 


( 0.9.2342.19200300.100.1.6 
NAME " roomNumber" 
EOUALITY caselgnoreMatch 
SUBSTR caselgnoreSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15(256) ) 


( 0.9.2342.19200300.100.1.21 
NAME ‘secretary’ 
EQUALITY distinguishedNameMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 


( 0.9.2342.19200300.100.1.1 

NAME ‘uid’ 

EQUALITY caseIgnoreMatch 

SUBSTR caselIgnoreSubstringsMatch 

SYNTAX 1.3.0.1:4:.1:.1466.115.121.1.150250]-) 
Note: RFC 1274 uses the longer name 'userid'. 


9.1.4. Attribute type from RFC 2079 


(.1:32:6.1.4.1.250.1.57 
NAME 'labeledURI' 
EQUALITY caseExactMatch 
SUBSTR caseExactSubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.14.15 ) 
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9.2. Syntaxes 
9.2.1. Syntaxes from RFC 2252 
( 1.3.6.1.4.1.1466.115.121 


( 1.3.6.1.4.1.1466.115.121 


( 1.3.6.1.4.1.1466.115.121. 
(1:32.68 1.4.1.14066.115.121. 
(2356. 1.4.1.1466.115.121.. 
( 1.3.6.1.4.1.1466.115.121. 
( 1.3.6.1.4.1.1466.115.121. 
( 1.3.6.1.4.1.1466.115.121. 
( 1:3.6.1.4.1.1466.115.121. 
C 1.3:26.1.4.1.1406.115.121. 
( 1.3.6;1.4.1.140606.115 121. 
C.1.3.6.1.4.1.1466.115.121. 


( 1.3.6.1.4.1.1466.115.121. 


9.2.2. Syntaxes from RFC 2256 


( 1.3.6.1.4.1.1466.115.121. 
(71.3.6. 1.4.1.1466.115.1241.. 
( 1.3.6.1.4.1.1466.115.121. 


(7L23926.1.4.1.1466.115.121. 


9.3. Matching Rules 


9.3.1. Matching rules from RFC 2252 


.1.5 DESC 'Binary' ) 


.1.6 DESC 'Bit String’ ) 


1:12 


1.5 


1.22 


1.26 


1.28 


1.36 


1.38 


1.41 


1.44 


1.50 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


DESC 


1.8 DESC 'Certificate' ) 


"DN" ) 

'Directory String’ ) 
'Facsimile Telephone Number' ) 
‘TAS String’ ) 

' JPEG' ) 

'Numeric String' ) 

'OID' ) 

'Postal Address' ) 

'Printable String' ) 


"Telephone Number’ ) 


"Delivery Method’ ) 
‘Octet String’ ) 
'Teletex Terminal Identifier’ ) 


'Telex Number’ ) 


Note that the original definition of many of these matching rules can 


be found in X.520. 
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( 2.5.13.16 NAME 'bitStringMatch' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 


953.25 


1 


.3.6.1.4.1.1466.109.114.2 NAME ’caseIgnoreIA5Match’ 


SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 


2 


.5.13.11 NAME 'caseIgnoreListMatch" 


SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 


2 


.5.13.2 NAME "caselgnoreMatch" 


SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


2 


.5.13.1 NAME 'distinguishedNameMatch"' 


SYNTAX 1:3.6.1.4.1.1466.115.121.1.12.) 


2 


.5.13.8 NAME "numericStringMatch" 


SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 


Zi. 


SYNTAX 


Ze 


5.13.0 NAME ’objectIdentifierMatch’ 
$3.46:1,4:1.1466.115.121.:1 138) 


H 


5.13.20 NAME 'telephoneNumberMatch' 


SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 


Matching rule from RFC 2256 


April 2000 


Note that the original definition of this matching rule can be found 
PY. 520% 


( 2.5.13.17 NAME ’octetStringMatch’ 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 


9.3.3 


Additional matching rules from X.520 


caseExactMatch 


( 


2.5.13.5 NAME "caseExactMatch" 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 


This rule determines whether a presented string exactly matches an 


attribute value of syntax DirectoryString. 
caselgnoreMatch except that case is not ignored. 


It is identical to 
Multiple adjoining 


whitespace characters are treated the same as an individual space, 
and leading and trailing whitespace is ignored. 
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caseExactSubstringsMatch 


( 2.5.13.7 NAME 'caseExactSubstringsMatch' 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 


This rules determines whether the initial, any and final substring 
elements in a presented value are present in an attribute value of 
syntax DirectoryString. It is identical to caseIgnoreSubstringsMatch 
except that case is not ignored. 


caselgnoreListSubstringsMatch 


( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 
SYNTAX. 1.3.6.1.4.1.1466.115.121.1.598 ) 


This rule compares a presented substring with an attribute value 
which is a sequence of DirectoryStrings, but where the case of 
letters is not significant for comparison purposes. A presented 
value matches a stored value if and only if the presented value 
matches the string formed by concatenating the strings of the stored 
value. Matching is done according to the caselgnoreSubstringsMatch 
rule except that none of the initial, final, or any values of the 
presented value match a substring of the concatenated string which 
spans more than one of the strings of the stored value. 


9.3.4. Matching rules not defined in any referenced document 
caselgnoreIA5SubstringsMatch 


( 1.3.6.1.4.1.1466.109.114.3 NAME "caselgnoreIA5SubstringsMatch" 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 


This rules determines whether the initial, any and final substring 
elements in a presented value are present in an attribute value of 
syntax IA5 String without regard to the case of the letters in the 
strings. It is expected that this matching rule will be added to an 
update of RFC 2252. 
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10. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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